-
Notifications
You must be signed in to change notification settings - Fork 404
Cut 0.0.107 #1525
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cut 0.0.107 #1525
Conversation
Waiting on #1517. |
CHANGELOG.md
Outdated
overwhelming default logging (#1421). | ||
* `PeerManager` supports processing messages from different peers in parallel | ||
(#1023). | ||
* `PeerManager` uses a single `Secp256k1` across all peers (#1472). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a perf improvement? I guess it's a memory usage thing but we should specify what impact things have, not what we did to get it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated but let me know if you prefer to drop it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe drop the how? Just say that we've reduced memory usage used per-peer in PeerManager
?
CHANGELOG.md
Outdated
* `BackgroundProcessor` process pending events before processing network | ||
messages to reduce lock contention in `ChannelManager`, which can be | ||
problematic for extremely slow machines (#1436). | ||
* Fixed an integer underflow during channel opening occurring when the channel |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did this actually change --release code? IIRC it does not have an impact, just corrects the error message - not sure it's worth even mentioning.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dropped
CHANGELOG.md
Outdated
been renamed `NetworkUpdate::ChannelFailure` (#1159). | ||
* Added a `filtered_block_connected` method to `chain::Listen` and a default | ||
implementation of `block_connected` in order to support BIP 157/158 compact | ||
block filters (#1453). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it's useful for compact block filters cause in that case you have the full block. Maybe just say "for those fetching filtered instead of full blocks"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed though note for compact block filters you still need to connect empty blocks if the filter doesn't match.
7913f17
to
6386716
Compare
Rebased to resolve a merge conflict in a Cargo file. |
Should mention greatly reduced memory usage due to rust-bitcoin / libsecp upgrade. |
`chainmonitor::Persist` are given for types implementing `KVStorePersister`. | ||
` lightning-persister`'s `FilesystemPersister` implements `KVStorePersister` | ||
(#1417). | ||
* `ChannelDetails` and `ChannelCounterparty` include fields for HTLC minimum |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure how detailed we want to be in these release notes, but here are two points that may be worth adding about #1378 and #1444:
- With Include htlc min/max for ChannelDetails and ChannelCounterparty #1378 the
lightning-invoice
crate now sets a value forhtlc_minimum_msat
andhtlc_maximum_msat
in the invoiceRouteHints
if such values exists. - Set
ChannelUpdate
htlc_maximum_msat
using the peer's value #1444 added a new config fieldmax_inbound_htlc_value_in_flight_percent_of_channel
that allows the user to specify the percentage of the channel value which the total value of outstanding inbound HTLCs for the channel will be capped to.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea, 1444 is unrelated here - it's a bugfix to set the value correctly. The new config knob is in the next bullet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea, 1444 is unrelated here - it's a bugfix to set the value correctly. The new config knob is in the next bullet.
Nice, thanks for adding the config knob as a separate bullet @jkczyz. This is now resolved after 1444 is removed from this bullet (+ the comment about the BOLT11 hints encoding below) :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK 6386716
CHANGELOG.md
Outdated
and maximum values (#1378, #1444). | ||
* `ProabilisticScorer` is parameterized by a `Logger`, which it uses to log | ||
channel liquidity updates or lack thereof (#1405). | ||
* `ChannelDetails` has a `outbound_htlc_limit_msat` field, which should be used |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit
* `ChannelDetails` has a `outbound_htlc_limit_msat` field, which should be used | |
* `ChannelDetails` has an `outbound_htlc_limit_msat` field, which should be used |
CHANGELOG.md
Outdated
unconfirmed rather than as it loses confirmations (#1461). | ||
* Fixed a panic in `lightning-net-tokio` when fetching a peer's socket address | ||
after the connection has been closed (#1449). | ||
* `find_route` will no longer return routes that would cause Onion construction |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: common noun?
* `find_route` will no longer return routes that would cause Onion construction | |
* `find_route` will no longer return routes that would cause onion construction |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe "in some cases"? In the Bug Fixes section I'd prefer we be as exact as possible, especially given we know of other cases where find_route can return routes that channelmanager will refuse lol.
CHANGELOG.md
Outdated
# 0.0.107 - 2022-06-07 | ||
|
||
## API Updates | ||
* Wumbo channels are now supported and can be enabled for inbound channels |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this really the most important API change we have in 107?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm... not sure. Figured given everyone else has supported it for ages, it's quite notable that we now do, too. Happy to push this down if you prefer.
CHANGELOG.md
Outdated
* Upgraded to `bitcoin` crate version 0.28.1 (#1389). | ||
* `ShutdownScript::new_witness_program` now takes a `WitnessVersion` instead of | ||
a `NonZeroU8` (#1389). | ||
* When a `channel_update` message is included in an onion error's `failuremsg`, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this is (really) an API change, more a bug fix or spec compliance, if its even worth documenting, but I think the bigger change is the bugfix where we support reading such messages, less generating them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Placed it in the spec compliance section and expanded to include reading. Let me know if you prefer the latter go under bug fixes.
CHANGELOG.md
Outdated
unconfirmed rather than as it loses confirmations (#1461). | ||
* Fixed a panic in `lightning-net-tokio` when fetching a peer's socket address | ||
after the connection has been closed (#1449). | ||
* `find_route` will no longer return routes that would cause Onion construction |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe "in some cases"? In the Bug Fixes section I'd prefer we be as exact as possible, especially given we know of other cases where find_route can return routes that channelmanager will refuse lol.
CHANGELOG.md
Outdated
overwhelming default logging (#1421). | ||
* `PeerManager` supports processing messages from different peers in parallel | ||
(#1023). | ||
* `PeerManager` uses a single `Secp256k1` across all peers (#1472). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe drop the how? Just say that we've reduced memory usage used per-peer in PeerManager
?
CHANGELOG.md
Outdated
which can be determined at runtime (#1423). | ||
* `lightning-invoice` crate's `utils` now accept an expiration time (#1422, | ||
#1474). | ||
* `find_route` now assumes variable-length onions by default (#1414). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
something about "nodes supporting" or something, as a user its entirely unclear to me what "variable-length onions" means or why find_route is assuming it, and where. Maybe we need a "spec compliance" "peer behavior changes" section to separate this out from developer-visible API changes? That would also include things like the warn-on-stale-peer, the channel_update failuremsg stuff, etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or another organization could be to document API breaking changes where we expect the user to take actions on from API extensions where we add new features and the user can stay passive? What are our users release deployment flow and which informations would they like to be prioritized ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Made a spec compliance section.
* `ChannelManager` serialization is no longer compatible with versions prior to | ||
0.0.99 (#1401). | ||
|
||
In total, this release features 96 files changed, 9304 insertions, 4503 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Phew this was a big release. API-change-wise too. Need to be more aggressive about shipping releases more often, IMO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice if we document the new features in the website
## API Updates | ||
* Wumbo channels are now supported and can be enabled for inbound channels | ||
using `ChannelHandshakeLimits::max_funding_satoshis` (#1425). | ||
* Support for feature `option_zeroconf`, allowing immediate forwarding of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be nice to document "zero-conf" in the website, maybe in a "Supported Features" subsection.
* `ChannelManager::claim_funds` no longer returns a `bool` to indicate success. | ||
Instead, an `Event::PaymentClaimed` is generated if the claim was successful. | ||
Likewise, `ChannelManager::fail_htlc_backwards` no longer has a return value | ||
(#1434). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The commit message of this specific change is saying "We can revisit this decision based on user feedback, but will need to very carefully document the potential failure modes here if we do", should we mark more explicitly as waiting feedback on that change ? Not sure folks are gonna read commit messages.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm more inclined to keep this brief and allow users to complain if they find it confusing.
Likewise, `ChannelManager::fail_htlc_backwards` no longer has a return value | ||
(#1434). | ||
* `lightning-rapid-gossip-sync` is a new crate for syncing gossip data from a | ||
server, primarily aimed at mobile devices (#1155). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same, would be nice to document it in the website. The README.md
is quite nice though not sure it's enough to guide a mobile dev to deploy a gossip sync server and integrate it in its own backend.
CHANGELOG.md
Outdated
which can be determined at runtime (#1423). | ||
* `lightning-invoice` crate's `utils` now accept an expiration time (#1422, | ||
#1474). | ||
* `find_route` now assumes variable-length onions by default (#1414). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or another organization could be to document API breaking changes where we expect the user to take actions on from API extensions where we add new features and the user can stay passive? What are our users release deployment flow and which informations would they like to be prioritized ?
CHANGELOG.md
Outdated
`debug_log_liquidity_stats` (#1460). | ||
* `BackgroundProcessor` now takes an optional `WriteableScore` which it will | ||
persist using the `Persister` trait's new `persist_scorer` method (#1416). | ||
* A `warn` message is now sent when receiving a `channel_reestablish` with an |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That type of change is nice to know if you're connecting with another implementation or old version but you don't really expect the user to change its application in consequence. At least it's a p2p relaxation here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moved to new spec section.
CHANGELOG.md
Outdated
identifiers have been renamed accordingly (#1506). | ||
* `core2::io` or `std::io` (depending on feature flags `no-std` or `std`) is | ||
exported as a `lightning::io` module (#1504). | ||
* The deprecated `Scorer` has been removed in favor or `ProbabilisitcScorer` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/ProbabilisitcScorer/ProbabilisticScorer/g
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: this typo still exists in the latest diff.
* `PeerManager` uses a single `Secp256k1` across all peers for reduced memory | ||
usage (#1472). | ||
|
||
## Bug Fixes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it misses #1454 ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And the sister PR #1463
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dropped in the fixup as per 483dd8e#r891072611
6386716
to
a2d78a9
Compare
Yeah, definitely need to improve that. We've been working on some visuals for a presentation that could be repurposed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Almost good. I'm happy to see this squashed regularly, dunno about other reviewers.
`chainmonitor::Persist` are given for types implementing `KVStorePersister`. | ||
` lightning-persister`'s `FilesystemPersister` implements `KVStorePersister` | ||
(#1417). | ||
* `ChannelDetails` and `ChannelCounterparty` include fields for HTLC minimum |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that these values are not encoded in the BOLT 11 hints, it's more of a forward compat thing. Don't think it's worth mentioning anything in the invoice here.
`chainmonitor::Persist` are given for types implementing `KVStorePersister`. | ||
` lightning-persister`'s `FilesystemPersister` implements `KVStorePersister` | ||
(#1417). | ||
* `ChannelDetails` and `ChannelCounterparty` include fields for HTLC minimum |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea, 1444 is unrelated here - it's a bugfix to set the value correctly. The new config knob is in the next bullet.
CHANGELOG.md
Outdated
|
||
## Spec Compliance | ||
* `find_route` now assumes variable-length onions by default for nodes | ||
supporting the feature (#1414). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Assumes.... for nodes supporting this feature" makes no sense. We assume it when we don't know if the node supports this feature now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, misinterpreted your earlier comment.
bump |
What exactly should we write for this? |
|
Lol easy enough. |
a2d78a9
to
9d11374
Compare
Codecov Report
@@ Coverage Diff @@
## main #1525 +/- ##
==========================================
+ Coverage 90.94% 90.95% +0.01%
==========================================
Files 80 80
Lines 43426 43426
Branches 43426 43426
==========================================
+ Hits 39492 39497 +5
+ Misses 3934 3929 -5
Continue to review full report at Codecov.
|
Squashed! Let me know if I missed anything. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM with two notes about backwards compat.
CHANGELOG.md
Outdated
* `ProbabilisticScorer` uses more precision when approximating `log10` (#1406). | ||
|
||
## Serialization Compatibility | ||
* `ChannelManager` serialization is no longer compatible with versions prior to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should also mention that channels with the zero Conf feature enabled (not required for 0conf channel use) will be unreadable by versions prior to 107.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this for both ChannelManager::accept_inbound_channel_from_trusted_peer_0conf
and ChannelHandshakeLimits::trust_own_funding_0conf
? Should this be called out in their respective docs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might have misread this. Was assuming you meant whenever Channel::set_0conf
. Was this comment specific about features set on the channel? Let me know if there's a phrasing that you would prefer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's kinda independent - we never set the feature, but still do 0conf. Inbound channel peers may set the feature, which would cause incompatibility.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's called out in inbound channel event docs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's kinda independent - we never set the feature, but still do 0conf. Inbound channel peers may set the feature, which would cause incompatibility.
Don't we set as optional in InitFeatures::known
?
BTW, pushed wording essentially what you said in the first comment. Let me know if you prefer different wording.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, its presence in the init/node features is pretty different from it in channel_type.
9d11374
to
e7e539e
Compare
CHANGELOG.md
Outdated
@@ -82,6 +230,9 @@ | |||
path with an overall lower cost (#1399). | |||
|
|||
## Serialization Compatibility | |||
* All above new events/fields are ignored by prior clients. All above new |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, did we have any new fields that this apply to in 106? I'm not sure that we did. Same goes for 105.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, removed.
e7e539e
to
a66b206
Compare
CHANGELOG.md
Outdated
identifiers have been renamed accordingly (#1506). | ||
* `core2::io` or `std::io` (depending on feature flags `no-std` or `std`) is | ||
exported as a `lightning::io` module (#1504). | ||
* The deprecated `Scorer` has been removed in favor or `ProbabilisitcScorer` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: this typo still exists in the latest diff.
a66b206
to
b2e635f
Compare
Sounds mentioning #1454 / #1463 in bug fix has been lost : #1525 (comment) ? |
Jeff responded at #1525 (comment) with a link that github has now eaten and decided we dont need to see :(. But the context there was I'd suggested dropping it since it just provides a better error message for otherwise-unusable channels. More of a "better error for a case you should never hit" which I'm not sure we need to document. Happy to revisit in a new PR editing CHANGELOG. |
FYI, here's a workable link to the discusison: #1525 (comment) |
No description provided.